I've already replied to specific comments, but I think these two points are worth discussing top-level:

It'd be good to differentiate installer from resolver and be consistent about that throughout the text.

I think the PEP as it stands right now roughly splits tools into "installers" and "everything else". The boundary between the two is a bit blurry, and I don't think we're really following it consistently.

The primary idea behind "installers" is that these are packages that need to be able to determine whether variant wheels are supported, and may be executed with elevated privileges. Therefore, from the security PoV there is a risk that variant wheels would require installing and running arbitrary packages with these privileges. The "everything else" is basically tools where we don't worry about that — e.g. tools that only need to process wheels without determining whether they are supported, or build tools that install and run arbitrary packages anyway.

I suppose "installers" is a bit of a misnomer, since there are technically other tools that need to determine whether wheels can be installed. However, I don't think "resolver" is a good replacement. I mean, saying that "resolver should vendor a plugin" is weird — the installer does that, resolver is merely one of its components. Furthermore, the same applies to cases where resolver isn't really used, e.g. when installing a wheel from the local filesystem.

I'm open to improving things, but I don't really have a better term than "installer", and I'm not sure if using a strictly more correct term won't make things harder to comprehend.

In the overview of the specification, there is a lot of discussion of mitigations and security measures that should be taken, but no discussion of what the security risks are and what the threat model is. People will want to see an acknowledgement of the risks, probably more than the current Security implications section.

Indeed. Probably the "security considerations" section needs to be rewritten to make the problem clearer. I wonder if it would make sense to move it prior to specification; describe the problem there, then the measures taken in the specification part.

A resolver isn't a standalone tool/package/thing from a packaging perspective, it's a component inside an installer. The relevant tools are "build backend", "build frontend", "installer".

Since resolvers are part of other tools like lockfile generators (e.g. pip-tools), I view resolvers as a component shared between installers and lockfile generators. Resolvers are used elsewhere too (e.g. tools to check licenses of various dependencies, etc.).

I think the PEP as it stands right now roughly splits tools into "installers" and "everything else". The boundary between the two is a bit blurry, and I don't think we're really following it consistently.

Yeah I think my main point is that the PEP makes specifications about package resolution, but tools other than installers do that.

However, I don't think "resolver" is a good replacement. I mean, saying that "resolver should vendor a plugin" is weird — the installer does that, resolver is merely one of its components.

One thing we could do is define "resolvers" as "tools which has a package resolution step". Or even use "resolver tools" (but maybe that is verbose).

Indeed. Probably the "security considerations" section needs to be rewritten to make the problem clearer. I wonder if it would make sense to move it prior to specification; describe the problem there, then the measures taken in the specification part.

I agree this seems like an improvement! Generally people don't move the sections around, but I think that should be fine since it is important to the flow of the PEP. We could also have a security section in the rationale I suppose.

I'll prepare an update for the security-related stuff tomorrow.